Unicast/multicast architecture

ABSTRACT

A system and method for providing content to users including a multicast sub-system providing content to multiple users and a unicast sub-system providing content to individual users. The multicast sub-system being operative to push to each of a plurality of user communities, content relating to the community and the unicast sub-system being operative to provide on demand to a user, content which has not been previously pushed to the user.

FIELD OF THE INVENTION

[0001] The present invention relates generally to systems andmethodologies for providing content to users via electronic media.

BACKGROUND OF THE INVENTION

[0002] The following patents and other publications are believed torepresent the current state of the art:

[0003] U.S. patent application Ser. No. 09/283,598 of Kipnis et al,filed Apr. 1, 1999, and corresponding published UK Patent Application2,351,891;

[0004] U.S. patent application Ser. No. 09/285,214 of Richardson et al,filed Apr. 1, 1999, and corresponding published UK Patent Application2,348,530;

[0005] a product called SQUID WEB PROXY CACHE, described at World WideWeb site www.squid.org;

[0006] an article by Steve Epstein et al, entitled “Macro and MicroScheduling”, published in NDS Technical Disclosure Bulletin, vol. 1,number 1, September 1999, at pages 6-8; and

[0007] the following RFC documents, available at World Wide Web sitewww.ietf.org:

[0008] 1. RFC 1945, entitled “Hypertext Transfer Protocol—HTTP/1.0”,dated May 1996.

[0009] 2. RFC 2186, entitled “Internet Cache Protocol (ICP), version 2”,dated September 1997.

[0010] 3. RFC 2187, entitled “Application of Internet Cache Protocol(ICP), version 2”, dated September 1997.

[0011] The disclosures of all references mentioned above and throughoutthe present specification are hereby incorporated herein by reference.

SUMMARY OF THE INVENTION

[0012] The present invention seeks to provide improved systems andmethodologies for providing content to users via electronic media

[0013] There is thus provided in accordance with a preferred embodimentof the present invention a system for providing content to usersincluding a multicast sub-system providing content to multiple users anda unicast sub-system providing content to individual users. Themulticast sub-system is operative to push to each of a plurality of usercommunities, content relating to the community and the unicastsub-system being operative to provide on demand to a user, content whichhas not been previously pushed to the user.

[0014] There is also provided in accordance with another preferredembodiment of the present invention a method for providing content tousers. The method includes steps of multicasting content to multipleusers and unicasting content to individual users. The step ofmulticasting includes pushing to each of a plurality of usercommunities, content relating to the community and the step of includesproviding on demand to user, content which has not been previouslypushed to the user.

[0015] There is also provided in accordance with a preferred embodimentof the present invention a system for providing content to userincluding a multicast sub-system providing content to multiple users andis operative to push to each of a plurality of user communities, contentrelating to the community and a bandwidth allocator operative toallocate bandwidth used by the multicast sub-system among the pluralityof user communities.

[0016] There is further provided in accordance with a preferredembodiment of the present invention a system for providing content tousers including at least one multicast sub-system providing content tomultiple users, at least one unicast sub-system providing content toindividual users and a bandwidth allocator operative to allocatebandwidth among the at least one multicast sub-system and the at leastone unicast sub-system.

[0017] There is provided in accordance with another preferred embodimentof the present invention a system for providing content to usersincluding a multicast sub-system providing content to multiple users andbeing operative to push to each of a plurality of user communities,content relating to the community based on at least a-priorideterminations and current demand and a bandwidth allocator operative toallocate bandwidth used by the multicast sub-system among at leastcontent based on a-priori determinations and content based on currentdemand.

[0018] There is also provided in accordance with yet another preferredembodiment of the present invention a system for providing content tousers including multicast means for providing content to multiple usersand unicast means for providing content to individual users, themulticast means being operative to push each of a plurality of usercommunities, content relating to the community and the unicast meansbeing operative to provide on demand to a user, content which has notbeen previously pushed to the user.

[0019] There is further provided in accordance with another preferredembodiment of the present invention a system for providing content touser including multicast means providing content to multiple users andbeing operative to push to each of a plurality of user communities,content relating to the community and bandwidth allocator meansoperative to allocate bandwidth used by the multicast means among theplurality of user communities.

[0020] There is also provided in accordance with a further preferredembodiment of the present invention a system for providing content tousers including at least one multicast means for providing content tomultiple users, at least one unicast means for providing content toindividual users and bandwidth allocator means operative to allocatebandwidth among the at least one multicast means and the at least oneunicast means.

[0021] There is further provided in accordance with yet anotherpreferred embodiment of the present invention a system for providingcontent to users. The system includes multicast means for providingcontent to multiple users and being operative to push to each of aplurality of user communities, content relating to the community basedon at least a priori determinations and current demand and a bandwidthallocator operative to allocate bandwidth used by the multicast meansamong at least content based on a priori determinations and contentbased on current demand.

[0022] There is also provided in accordance with yet another preferredembodiment of the present invention a system for providing unicast andmulticast content to users and including bandwidth allocation means forproviding a guaranteed minimum level of unicast service to the extentrequired and wherein bandwidth remaining from the provision of theguaranteed minimum level of unicast service is employed for multicast,the same broadcast network providing both unicast and multicast.

[0023] There is further provided in accordance with a preferredembodiment of the present invention a system for providing unicast andmulticast content to users and including bandwidth allocation means forallocating highest priority to a-priori content and next highestpriority to unicast and for allocating remaining bandwidth to multicast.

[0024] Further in accordance with a preferred embodiment of the presentinvention the system also includes a plurality of satellites having atleast one of the following functionalities: broadcast, multicast andunicast.

[0025] Still further in accordance with a preferred embodiment of thepresent invention the system also includes at least one of cablenetworks, digital terrestrial networks, microwave networks, cellularnetworks and DSL networks, having at least one of the followingfunctionalities: broadcast, multicast and unicast.

[0026] Preferably, the unicast functionality is provided by facilities,which also simultaneously provide broadcast and multicastfunctionalities.

[0027] Additionally in accordance with a preferred embodiment of thepresent invention the broadcast includes transmission of content to allusers within a geographical footprint of a broadcast, includingtransmission of content in a pay access regime.

[0028] Further in accordance with a preferred embodiment of the presentinvention the multicast includes transmission of content to all userswithin a community having a predefined common interest, within ageographical footprint of a broadcast.

[0029] Still further in accordance with a preferred embodiment of thepresent invention the unicast includes transmission of content to anindividual user based on a request from that user.

[0030] Further in accordance with a preferred embodiment of the presentinvention at least one coordinating facility coordinates unicastfunctionality with at least one of broadcast and multicastfunctionalities, thereby to enable efficient and effective use ofavailable resources in terms of transmission facilities and bandwidth.

[0031] Preferably, the coordinating functionality provides at least oneof the following functionalities: shifting between unicasting andmulticasting, bandwidth allocation within multicast communities andbandwidth allocation between unicast, multicast and a priori broadcastor multicast content.

[0032] Additionally or alternatively the coordinating functionality isoperative to determine what content is sent in what manner at what timevia which facilities to which users.

[0033] Preferably, one coordinating functionality is operative to createnew multicast communities in response to an increase in common userinterests and requests.

[0034] Further in accordance with a preferred embodiment of the presentinvention the one coordinating functionality is operative to eliminatemulticast communities in response to a decrease in common user interestsand requests.

[0035] Preferably, as a community grows, the amount of bandwidthallocated to that community increases. Additionally, as a communitydecreases in size, the amount of bandwidth allocated to that communitydecreases.

[0036] Additionally or alternatively, there is defined a minimummulticast threshold which is a relative threshold determined by relativedemands for various available content.

[0037] Preferably, the system provides a guaranteed minimum level ofunicast service to the extent required and wherein bandwidth remainingfrom the provision of the guaranteed minimum level of unicast service isemployed for multicast, the same broadcast network providing bothunicast and multicast.

[0038] Still further in accordance with a preferred embodiment of thepresent invention the bandwidth not required for contractual unicastservice is allocated to multicast, thereby reducing demand forcontractual unicast service and thus, over time, decreasing latency andproviding enhanced service to customers.

[0039] Additionally in accordance with a preferred embodiment of thepresent invention the bandwidth not required for contractual unicastservice is allocated not only to multicast but also to better unicastservice, in accordance with latency considerations.

[0040] Further in accordance with a preferred embodiment of the presentinvention the available bandwidth is allocated with the highest prioritybeing given to a-priori content and the next highest priority beinggiven to unicast, the remaining bandwidth being employed for multicast.

[0041] Preferably, the remaining bandwidth is allocated amongcommunities based at least partially on relative community size.

[0042] There is provided in accordance with another preferred embodimentof the present invention a method for providing content to user. Themethod includes the steps of multicasting content to multiple users bypushing content relating to individual communities and allocatingbandwidth among the individual communities.

[0043] There is also provided in accordance with a further preferredembodiment of the present invention a method for providing content tousers. The method includes the steps of multicasting content to multipleusers, unicasting content to individual users and allocating bandwidthbetween the multicasting and the unicasting.

[0044] There is further provided in accordance with a preferredembodiment of the present invention a method for providing content tousers. The method includes multicasting content to multiple users bypushing to each of a plurality or user communities, content relating tothe community based on at least a priori determinations and currentdemand and allocating bandwidth among at least content based on a priorideterminations and content based on current demand.

[0045] There is also provided in accordance with yet a further preferredembodiment of the present invention a method for providing unicast andmulticast content to users and including bandwidth allocation whereinbandwidth remaining from the provision of the guaranteed minimum levelof unicast service is employed for multicast, the same broadcast networkproviding both unicast and multicast.

[0046] There is further provided in accordance with yet anotherpreferred embodiment of the present invention a method for providingunicast and multicast content to users. The method includes bandwidthallocation, allocating highest priority to a-priori content and nexthighest priority to unicast and for allocating remaining bandwidth tomulticast.

[0047] Additionally in accordance with a preferred embodiment of thepresent invention the method also includes the broadcast of content toall users within a geographical footprint of a broadcast, includingtransmission of content in a pay access regime.

[0048] Still further in accordance with a preferred embodiment of thepresent invention the step of multicasting includes transmission ofcontent to all users within a community having a predefined commoninterest, within a geographical footprint of a broadcast.

[0049] Further in accordance with a preferred embodiment of the presentinvention the step of unicasting includes transmission of content to anindividual user based on a request from that user.

[0050] Moreover in accordance with a preferred embodiment of the presentinvention at least one coordinating facility coordinates unicastfunctionality with at least one of broadcast and multicastfunctionalities, thereby to enable efficient and effective use ofavailable resources in terms of transmission facilities and bandwidth.

[0051] Preferably, the coordinating functionality provides at least oneof the following functionalities: shifting between unicasting andmulticasting, bandwidth allocation within multicast communities andbandwidth allocation between unicast, multicast and a priori broadcastor multicast content.

[0052] Additionally or alternatively, the coordinating functionality isoperative to what content is sent in what manner at what time facilitiesto which users.

[0053] Further in accordance with a preferred embodiment of the presentinvention the coordinating functionality is operative to create newmulticast communities in response to an increase in common userinterests and requests.

[0054] Additionally in accordance with a preferred embodiment of thepresent invention the coordinating functionality is operative toeliminate multicast communities in response to a decrease in common userinterests and requests.

[0055] Further in accordance with a preferred embodiment of the presentinvention, as a community grows, the amount of bandwidth allocated tothat community increases.

[0056] Additionally or alternatively, as a community decreases in size,the amount of bandwidth allocated to that community decreases.

[0057] Still further in accordance with a preferred embodiment of thepresent invention the method also includes the step of providing aguaranteed minimum level of unicast service to the extent required andwherein bandwidth remaining form the provision of the guaranteed minimumlevel of unicast service is employed for multicast, the same broadcastnetwork providing both unicast and multicast.

[0058] Further in accordance with a preferred embodiment of the presentinvention, the bandwidth not required for contractual unicast service isallocated to multicast, thereby reducing demand for contractual unicastservice and thus, over time, decreasing latency and providing enhancedservice to customers.

[0059] Preferably, the bandwidth not required for contractual unicastservice is allocated not only to multicast but also to better unicastservice, in accordance with latency considerations.

[0060] Additionally or alternatively, the available bandwidth isallocated with the highest priority being given to a-priori content andthe next highest priority being given to unicast, the remainingbandwidth employed being for multicast.

[0061] Preferably, the remaining bandwidth is allocated amongcommunities based at least partially on relative community size.

BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The present invention will be understood and appreciated morefully from the following detailed description, taken in conjunction withthe drawings in which:

[0063]FIG. 1 is a simplified and generalized pictorial illustration ofan integrated multicast/unicast system and methodology for providingcontent to users via electronic media,

[0064]FIGS. 2A, 2B & 2C are illustrations of three typical operativestates of an integrated multicast/unicast system and methodology of thetype shown in FIG. 1 illustrating shifts between unicasting andmulticasting;

[0065]FIGS. 3A, 3B & 3C are illustrations of three typical operativestates of an integrated multicast/unicast system and methodology of thetype shown in FIG. 1 illustrating bandwidth allocation among and withincommunities;

[0066]FIGS. 4A, 4B & 4C are illustrations of three typical operativestates of an integrated multicast/unicast system and methodology of thetype shown in FIG. 1 illustrating bandwidth allocation between unicast,multicast and a priori content;

[0067]FIG. 5A is a set of diagrams showing changes in bandwidthallocation and latency over time in accordance with the prior art;

[0068]FIG. 5B is a set of diagrams showing changes in bandwidthallocation and latency over time in accordance with one preferredembodiment of the present invention;

[0069]FIG. 5C is a set of diagrams showing changes in bandwidthallocation and latency over time in accordance with another preferredembodiment of the present invention;

[0070]FIG. 6A is a diagram showing changes in bandwidth allocation overtime in accordance with the prior art;

[0071]FIG. 6B is a diagram showing changes in bandwidth allocation overtime in accordance with one preferred embodiment of the presentinvention;

[0072]FIG. 6C is a diagram showing changes in bandwidth allocation overtime in accordance with another preferred embodiment of the presentinvention;

[0073]FIG. 6D is a diagram showing changes in bandwidth allocation overtime in accordance with yet another preferred embodiment of the presentinvention;

[0074]FIG. 6E is a diagram showing changes in bandwidth allocation overtime in accordance with still another preferred embodiment of thepresent invention;

[0075]FIGS. 7A, 7B and 7C are simplified functional block diagramsillustrating three alternative functionalities of the system shown inFIG. 1;

[0076]FIGS. 8A and 8B are simplified functional block diagramsillustrating two alternative realizations of the functionality describedin FIGS. 3A-3C and FIG. 7A;

[0077] FIGS. 9A/1, 9A/2, 9B/1 and 9B/2 are simplified flow diagramscorresponding respectively to the simplified functional block diagramsof FIGS. 8A and 8B;

[0078]FIGS. 10A and 10B are simplified functional block diagramsillustrating two alternative realizations of the functionality describedin FIGS. 4A & 4B and FIG. 7B;

[0079] FIGS. 11A/1, 11A/2, 11B/1 and 11B/2 are simplified flow diagramscorresponding respectively to the simplified functional block diagramsof FIGS. 10A and

[0080]FIGS. 12A and 12B are simplified functional block diagramsillustrating two alternative realizations of the functionality describedin FIGS. 4C and FIG. 7C;

[0081] FIGS. 13A/1, 13A/2, 13B/1 and 13B/2 are simplified flow diagramscorresponding respectively to the simplified functional block diagramsof FIGS. 12A and 12B;

[0082]FIG. 14 is a simplified flowchart illustrating the operation of analgorithm for bandwidth allocation in an unicast-multicast environment,wherein unicast and multicast do not share the same bandwidth;

[0083]FIG. 15 is a simplified flowchart illustrating the operation of analgorithm for bandwidth allocation in a unicast-multicast environment,wherein unicast and multicast do share the same bandwidth; and

[0084]FIG. 16 is a simplified flowchart illustrating the operation of analgorithm for bandwidth allocation in an unicast-multicast environment,wherein unicast, a priori multicast and triggered multicast share thesame bandwidth.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0085] Reference is now made to FIG. 1, which is a simplified andgeneralized pictorial illustration of an integrated multicast/unicastsystem and methodology for providing content to users via electronicmedia.

[0086] As seen in FIG. 1 there is provided an integratedmulticast/unicast system which typically includes a plurality ofsatellites 100 which have at least one and preferably all of thefollowing functionalities: broadcast, multicast and unicast. Broadcast,multicast and unicast functionalities may also be provided by cablenetworks, digital terrestrial networks, microwave networks, cellularnetworks and DSL networks, as well as any other broadband facilities.Unicast functionality may additionally be provided by PSTN facilities.

[0087] It is appreciated that unicast functionality may or may not beprovided by facilities, which also simultaneously provide broadcast andmulticast functionalities.

[0088] Throughout, the following definitions are employed:

[0089] BROADCAST—transmission of content to all users within ageographical footprint of a broadcast, including transmission of contentin a pay access regime;

[0090] MULTICAST—transmission of content to all users within a communityhaving a predefined common interest, within a geographical footprint ofa broadcast;

[0091] UNICAST—transmission of content to an individual user based on arequest from that user, including, for example, HTTP or FTP.

[0092] In accordance with a preferred embodiment of the presentinvention, one or more coordinating facilities, symbolized by a block102, coordinate the unicast functionality with at least one andpreferably both of the broadcast and multicast functionalities, therebyto enable most efficient and effective use of available resources interms of transmission facilities and bandwidth. This coordination, aswill be described hereinbelow in detail, may take the form of shiftingbetween unicasting and multicasting and is described hereinbelow withrespect to FIGS. 2A, 2B and 2C, bandwidth allocation within multicastcommunities, as described hereinbelow with respect to FIGS. 3A, 3B and3C, bandwidth allocation between unicast, multicast and a prioribroadcast or multicast content, other tradeoffs and various combinationsand subcombinations of the foregoing.

[0093] Coordinating facilities 102 preferably determine what content issent in what manner at what time via which facilities to which users.For example, coordinating facilities 102 govern terrestrial unicasttransmissions, symbolized by arrows 104, satellite unicasttransmissions, symbolized by an arrow 106 and satellite broadcasts andmulticasts symbolized by footprints 108.

[0094] Reference is now made to FIGS. 2A, 2B & 2C, which areillustrations of three typical operative states of an integratedmulticast/unicast system and methodology of the type shown in FIG. 1illustrating shifts between unicasting and multicasting.

[0095]FIG. 2A shows multicasting from a coordinating center 200 to aplurality of multicast communities, typically including a businessmulticast community 202, a sports multicast community 204 and a youthmulticast community 206. The symbolism employed in FIGS. 2A-2C indicatesthe size of the community by the number of individuals showntherewithin. FIG. 2A also shows a user 208 who receives science contentvia a unicast and also a user 210, who is a member of the businessmulticast community 202, who also receives nature content via a unicast.

[0096] A comparison of FIG. 2B with FIG. 2A shows the creation of a newnature multicast community 212, which may overlap with another multicastcommunity, such as the business multicast community 202, to indicatethat a user may belong to multiple multicast communities simultaneously.

[0097] It is appreciated that mew communities are created in response toan increase in common user interests and requests. Thus, as symbolizedby an additional user having nature interests in FIG. 2B, when thenumber of users expressing a common interest reaches an appropriatethreshold, a new multicast community may be automatically created inaccordance with the present invention.

[0098]FIG. 2C shows an opposite trend from that illustrated in FIG. 2Bwherein due to a decrease in common user interests and requests,multicast communities are eliminated. Thus, as symbolized by removal ofa user previously having sports interests, designated by referencenumeral 214 in FIG. 2C, causing the number of users expressing a commoninterest in sports to fall below an appropriate threshold, the sportscommunity 204 appearing in FIG. 2A is automatically eliminated inaccordance with the present invention as shown in FIG. 2C.

[0099] Reference is now made to FIGS. 3A, 3B & 3C, which areillustrations of three typical operative states of an integratedmulticast/unicast system and methodology of the type shown in FIG. 1illustrating bandwidth allocation among and within communities.

[0100] As seen in FIGS. 3A and 3B, as a community grows, here indicatedsymbolically by the number of individuals located with a circlerepresenting the community, the amount of bandwidth allocated to thatcommunity, here indicated symbolically by the radius of the circle,increases. Concomitantly, as a community decreases in size, the amountof bandwidth allocated to that community decreases. An increase in thesize of the community and thus in the bandwidth allocation thereto isexemplified by the youth community at the right of FIGS. 3A and 3B. Adecrease in the size of the community is exemplified by the businesscommunity at the left of FIGS. 3A and 31B.

[0101] A comparison of FIGS. 3B and 3C illustrates typical bandwidthallocation within a community. It is seen that a symbolic member of thecommunity, indicated by reference numeral 302, who was receiving Disneyin FIG. 3B, shifts to Warner Bros. in FIG. 3C. This, when statisticallysignificant, results in a reallocation of bandwidth between Disney andWarner Bros. in FIG. 3C. In this case, whereas Warner Bros. was unicastin FIG. 3B to a symbolic member of the community, indicated by referencenumeral 304, the increased demand for Warner Bros. in FIG. 3C passes aminimum multicast threshold and causes Warner Bros. to be multicast inFIG. 3C. Concomitantly, the decreased demand for Disney causes Disney,which was multicast in FIG. 3B to be unicast to a symbolic member of thecommunity 306 in FIG. 3C.

[0102] It is appreciated that the minimum multicast threshold istypically not an absolute threshold but rather a relative thresholddetermined by relative demands for various available content.

[0103] It is appreciated that in the embodiment of FIGS. 3A-3C unicastbandwidth is not provided by the broadcast network and does not employits bandwidth.

[0104] Reference is now made to FIGS. 4A, 4B & 4C, which areillustrations of three typical operative states of an integratedmulticast/unicast system and methodology of the type shown in FIG. 1illustrating bandwidth allocation between unicast, multicast and apriori content. In the embodiment of FIGS. 4A-4C, as contrasted withthat of FIGS. 3A-3C, there is provided a guaranteed minimum level ofunicast service to the extent required. Bandwidth remaining from theprovision of the guaranteed minimum level of unicast service is employedfor multicast. It is assumed that the same broadcast network providesboth unicast and multicast, which is quite common in cable and DSLservice.

[0105] Considering FIGS. 4A and 4B, it is seen that the amount ofunicast demand decreases from FIG. 4A to FIG. 4B. This increases theamount of bandwidth available for multicast. As seen in FIG. 4B,typically the business community takes up this added bandwidth inasmuchas Bloomberg, a business service, is now multicast.

[0106] In this context, reference is also made to FIG. 5A, which showsdynamic allocation over time of available bandwidth between contractualunicast service and better unicast service in accordance with the priorart It is seen that in the prior art, generally the greater thepercentage of contractual unicast service, the greater the resultinglatency. Thus better service, i.e. lower latency results from lowereddemands for contractual unicast service.

[0107] In accordance with the present invention, as exemplified by FIG.5B, bandwidth not required for contractual unicast service is allocatedto multicast, as described hereinabove with reference to FIGS. 4A and4B. The availability of multicast service reduces the demand forcontractual unicast service and thus, over time, the latency decreases,providing enhanced service to customers. It is noted particularly thatthe availability of multicast service inherently reduces latency sincecontent is pushed to and cashed at the customer and thus can beretrieved instantaneously.

[0108]FIG. 5C illustrates a further enhancement of the inventiondescribed hereinabove with reference to FIGS. 4A and 4B. In FIG. 5C,bandwidth left over from contractual unicast service is allocated notonly to multicast but also, in certain cases to better unicast service.Typically a determination whether to allocate the left over bandwidth tomulticast or to better unicast service is made based on exceedance of aminimum multicast threshold, which is preferably absolute but may bedetermined by relative demands for content.

[0109] It is appreciated that the scenario of FIG. 5C is typically onewherein there is available sufficient bandwidth for all required contentand the allocation of the remaining bandwidth is made purely orprincipally based on latency considerations, predicated on theunderstanding that lower latency is translated into increased customersatisfaction.

[0110] It may thus be appreciated from a comparison of the latency shownin FIGS. 5B and SC, that the enhancement of FIG. 5C produces an overalldecrease in latency over time.

[0111]FIG. 4C shows a somewhat more complex situation than that shown inFIG. 4A, wherein there also exists an a-priori commitment to broadcastor multicast a certain amount of content determined by a contractualarrangement with a content provider. In such a case the availablebandwidth is allocated with the highest priority being given to thea-priori content and the next highest priority being given to unicast.The remaining bandwidth is employed for multicast and is allocated amongand within communities typically in a manner similar to that describedhereinabove with reference to FIGS. 1A-3C.

[0112] In this context, reference is also made to FIG. 6A, which showsdynamic allocation over time of available bandwidth between a prioribroadcast or multicast, typically including EPG (Electronic ProgramGuide), contractual unicast service and better unicast service inaccordance with the prior art.

[0113]FIG. 6B shows dynamic allocation over time of available bandwidthbetween a priori broadcast or multicast, typically including EPG(Electronic Program Guide), contractual unicast service and multicast ondemand in accordance with the present invention.

[0114]FIG. 6C shows dynamic allocation over time of available bandwidthbetween a priori broadcast or multicast, typically including EPG(Electronic Program Guide), contractual unicast service, better unicastservice and multicast on demand in accordance with the presentinvention.

[0115]FIG. 6D shows dynamic allocation over time of available bandwidthbetween a priori broadcast or multicast, which is now divided intorequired content and nice to have content and typically includes EPG(Electronic Program Guide), contractual unicast service, better unicastservice and multicast on demand in accordance with the presentinvention.

[0116]FIG. 6E shows dynamic allocation over time of available bandwidthbetween a priori broadcast or multicast, which is now divided intorequired content and nice to have content and typically includes EPG(Electronic Program Guide), contractual unicast service, better unicastservice and multicast on demand in accordance with the presentinvention. The difference between FIG. 6E and FIG. 6D is the allocationto multicast of some of the bandwidth, which is used for nice to havecontent.

[0117] Reference is now made to FIGS. 7A, 7B and 7C, which aresimplified functional block diagrams illustrating three alternativefunctionalities of the system shown in FIG. 1 employing asymmetricnetworks including non-balanced forward and return paths, wherein theforward path has substantially greater bandwidth than the return path.

[0118]FIG. 7A provides functionality suitable for use in the systemsshown in FIGS. 3A-3C. FIG. 7B provides functionality suitable for use inthe systems shown in FIGS. 4A & 4B and FIG. 7C provides functionalitysuitable for use in the system shown in FIG. 4C.

[0119] As seen in FIG. 7A, typically first and second end users 702 and704 are enabled to surf the Internet using a conventional PSTN network706, which defines a two-way return path. In the course of surfing theInternet, one or more of the end users may communicate with a web server708, which may be a conventional web server.

[0120] In accordance with a preferred embodiment of the presentinvention, the web server 708 may cause a multicast delivery server 710to transmit web content via a bandwidth allocator 712, which typicallyincludes bandwidth allocation decision functionality, a multiplexer anda modulator. Bandwidth allocator 712 preferably transmits contentreceived from multicast delivery server 710 via a broadband forward path714, typically including one or more satellites 716 to the first andsecond end users 702 and 704, to the extent of available allocatedbandwidth of the one or more satellites 716. Additionally oralternatively bandwidth allocator 712 may transmit over any suitableforward path, including a broadcast network such as a cable network 717,a digital terrestrial network 719 or an ADSL network (not shown).

[0121] Referring now to FIG. 7B, it is seen that typically first andsecond end users 722 and 724 are enabled to surf the Internet via aforward path and a return path. The return path, is a one-way, typicallyout of band, return path via an asymmetric network, such as a VSATnetwork, a DOCSIS cable network or an ADSL network. The forward pathemploys the same network that is used for the return path, indistinction to the structure of FIG. 7A.

[0122] In the embodiment of FIG. 7B, the end users 722 and 724 queryover the one-way return path indicated by arrows 726 via a one-wayreturn path hub 728, such as a conventional VSAT hub, a CMTS or a DSLAM.In the course of surfing the Internet, one or more of the end users maycommunicate with a web server 730, which may be a conventional webserver.

[0123] In accordance with a preferred embodiment of the presentinvention, the web server 730 may cause a multicast delivery server 732to transmit web content via a bandwidth allocator 734, which typicallyincludes bandwidth allocation decision functionality, a multiplexer anda modulator. Bandwidth allocator 734 preferably transmits contentreceived from multicast delivery server 732 via a broadband forward path733, typically including one or more satellites 736 to the first andsecond end users 722 and 724, to the extent of available allocatedbandwidth of the one or more satellites 736. Additionally oralternatively bandwidth allocator 734 may transmit over any suitableforward path, including a broadcast network such as a cable network 737,a digital terrestrial network 739 or an ADSL network (not shown).

[0124] Referring now to FIG. 7C, it is seen that typically first andsecond end users 752 and 754 are enabled to surf the Internet via aforward path and a return path The return path, is a one-way, typicallyout of band, return path via an asymmetric network, such as a VSATnetwork, a DOCSIS cable network or an ADSL network. The forward pathemploys the same network that is used for the return path, indistinction to the structure of FIG. 7A.

[0125] In the embodiment of FIG. 7C, the end users 752 and 754 queryover the one-way return path indicated by arrows 756 via a one-wayreturn path hub 758, such as a conventional VSAT hub, a CMTS or a DSLAM.In the course of surfing the Internet, one or more of the end users maycommunicate with a web server 760, which may be a conventional webserver.

[0126] In accordance with a preferred embodiment of the presentinvention, the web server 760 may cause a multicast delivery server 762to transmit web content via a bandwidth allocator 764, which typicallyincludes bandwidth allocation decision functionality, a multiplexer anda modulator.

[0127] The bandwidth allocator 764 may also concurrently receive contentvia an a-priori broadcaster server 765 from one or more contentproviders 766. Bandwidth allocator 764 preferably transmits contentreceived from multicast delivery server 762 and a-priori broadcastserver 765 via a broadband forward path 767, typically including one ormore satellites 768 to the first and second end users 752 and 754, tothe extent of available allocated bandwidth of the one or moresatellites 768.

[0128] Additionally or alternatively bandwidth allocator 764 maytransmit over any suitable forward path, including a broadcast networksuch as a cable network 769, a digital terrestrial network 770 or anADSL network (not shown).

[0129] It is appreciated that essential differences between thestructures shown in FIGS. 7A, 7B and 7C appear in bandwidth allocationdecisions. In the embodiment of FIG. 7A, the bandwidth is allocatedamong various multicast transmissions. In the embodiment of FIG. 7B, thebandwidth is allocated not only between various multicast transmissionsbut also between various unicast content transmissions. In theembodiment of FIG. 7C, the bandwidth is allocated additionally amonga-priori broadcasts.

[0130] Reference is now made to FIGS. 8A and 8B, which are simplifiedfunctional block diagrams illustrating two alternative realizations ofthe functionality described in FIGS. 3A-3C. Referring initially to FIG.8A, typically two end-user clients 800 and 802 are shown, it beingunderstood that a multiplicity of such end-user clients employ thesystem. Each of the end user clients 800 and 802 preferably includes abrowser 804 who communicates with a plug-in profiler 806 and with astandard web cache 808.

[0131] The standard web cache 808 may be a standard cache such as anMICROSOFT INTERNET EXPLORER cache or alternatively may be an externalproxy cache such as an APACHE proxy cache.

[0132] The combination of browser 804 and cache 808 is employed forconventional web surfing wherein the browser 804 initially checks cache808 for requested URLs and only queries a web server, such as thecommunity web server 818, when the requested URL is not in cache or outof date.

[0133] Plug-in profiler 806 stores historical surfing informationrelating to pages requested by the browser 804. Profiler 806communicates with a community creation server 810 at predetermined timesor at times responsive to various possible criteria The communitycreation server 810 preferably communicates with all end-user clientprofilers 806. Community creation server 810 preferably analyzes theclient profiles and, on the basis of this analysis, dynamically creates,modifies and deconstructs communities.

[0134] The community creation server 810 preferably outputs to acommunity set-up manager 812, which configures the various end users inaccordance with community creation/modification/deconstructioninstructions received from server 810. Community set-up manager 812 alsointerfaces with a bandwidth allocator 814 in order to enable thebandwidth allocator 814 to make appropriate bandwidth allocationdeterminations.

[0135] Community set-up manager 812 also interfaces with aunicast/multicast decision switch 816, which is operative to sendcontent by unicast, until the simultaneous demand for such contentjustifies sending the content by multicast. Unicast/multicast decisionswitch 816 is preferably incorporated into a community web server 818.

[0136] In accordance with a preferred embodiment of the presentinvention, each community is served by a single community web server 818and associated unicast/multicast decision switch 816.

[0137] When and so long as simultaneous demand for a given web pageexceeds a given threshold, unicast/multicast switch 816 triggersbandwidth allocator 814 to allocate multicast forward path bandwidth formulticast of that web page. Bandwidth allocator 814 may employ a dynamicpre-emptive queue of URLs for such allocation.

[0138] In practice, the bandwidth allocator 814 may be responsive to theamount of available bandwidth for dynamically changing the threshold ofswitch 816.

[0139] Bandwidth allocator 814 also interfaces with a multicast set-upmanager 820 which in turn interfaces with a multicast announcementserver 822 and a multicast delivery server 824. The multicastannouncement server 822 is operative to announce to all end users in agiven community the estimated time and address of upcoming multicasts.The multicast delivery server 824 is operative to deliver the multicaststo the cache 808, of each end user client 802 associated with the givencommunity.

[0140] Referring now to FIG. 8B, it is appreciated that whereas in theembodiment of FIG. 8A, each community is served by a centralizedcommunity web server 818, in the embodiment of FIG. 8B, a generic webserver facility 850, including one or more servers which may be atdisparate locations, is employed to serve multiple communities. In thisembodiment the generic web server facility 850 communicates with endusers without regard to the communities to which they belong. Therefore,in the embodiment of FIG. 8B, a bandwidth allocator 854 is preferablyco-located with a unicast/multicast decision switch 856.

[0141] In the embodiment of FIG. 8B, a community set-up manager 852interfaces with the unicast/multicast decision switch 856, hereincorporated with bandwidth allocator 854, and need not interface withthe generic web server 850. Preferably, in the embodiment of FIG. 8B,decisions as to which content to multicast or unicast and-as to theamount of bandwidth to allocate to the various multicasts are made bythe co-located unicast/multicast decision switch 856 and bandwidthallocator 854. Therefore, the generic web server facility 850 isrequired to continually update the unicast/multicast decision switch 856as to all web pages queried and as to the community identificationthereof.

[0142] The remainder of the embodiment of FIG. 8B is identical to thatof FIG. 8A. Identical elements are identified in FIG. 8B by the samereference numerals employed in FIG. 8A.

[0143] The embodiment of FIG. 8B has an advantage over the embodiment ofFIG. 8A in that in FIG. 8B, the web servers are generic and distributedamong the various communities. A disadvantage of the embodiment of FIG.8B relative to the embodiment of FIG. 8A is that greatly enhancedtraffic is generated between generic web server facility 850 and theunicast/multicast decision switch 856.

[0144] Reference is now made to FIGS. 9A and 9B, which are simplifiedflow diagrams corresponding respectively to the simplified functionalblock diagrams of FIGS. 8A and 8B.

[0145] Turning to FIG. 9A, it seen that along a time scale from the topof FIG. 9A to the bottom thereof, initially users conduct browsing usingbrowser 804 prior to formation of any community. Eventually, due toaction of the profiler 806, a community is formed by community set-upmanager 812 in response to a trigger from community creation server 810.

[0146] Following formation of a community, when end users who aremembers of the community engage in browsing, using browser 804, and whenthe demand among members of the community for a given web page exceeds athreshold established by unicast/multicast decision switch 816 of thecommunity web server 818, the content of the given web page is multicastto the entire community subject to bandwidth availability constraints.

[0147] Following the multicast, end users of the community can accessthe content of the given web page from their local cache with nearlyzero latency.

[0148] Referring now to FIG. 9B, it is seen that the states of thefunctionality may be identical to those shown in FIG. 9A. A principaldifference is in that whereas in the embodiment of FIG. 9A, thethreshold is established by unicast/multicast decision switch 816 of thecommunity web server 818, in the embodiment of FIG. 9B, the threshold isestablished by the unicast/multicast decision switch 856 co-located withthe bandwidth allocator 854.

[0149] Reference is now made to FIGS. 10A and 10B, which are simplifiedfunctional block diagrams illustrating two alternative realizations ofthe functionality described in FIGS. 4A & 4B and FIG. 713, and to FIGS.11A and 11B are simplified flow diagrams corresponding respectively tothe simplified functional block diagrams of FIGS. 10A and 10B.

[0150] Referring initially to FIG. 10A, typically two end-user clients1000 and 1002 are shown, it being understood that a multiplicity of suchend-user clients employ the system. Each of the end user clients 1000and 1002 preferably includes a browser 1004, which communicates with aplug-in profiler 1006 and with a standard web cache 1008.

[0151] The standard web cache 1008 may be a standard cache such as anMICROSOFT INTERNET EXPLORER cache or alternatively may be an externalproxy cache such as an APACHE proxy cache.

[0152] The combination of browser 1004 and cache 1008 is employed forconventional web surfing wherein the browser 1004 initially checks cache1008 for requested URLs and only queries a web server, such as thecommunity web server 1018, when the requested URL is not in cache or outof date.

[0153] Plug-in profiler 1006 stores historical surfing informationrelating to pages requested by the browser 1004. Profiler 1006communicates with a community creation server 1010 at predeterminedtimes or at times responsive to various possible criteria.

[0154] The community creation server 1010 preferably communicates withall is end-user client profilers 1006. Community creation server 1010preferably analyzes the client profiles and, on the basis of thisanalysis, dynamically creates, modifies and deconstructs communities.

[0155] The community creation server 1010 preferably outputs to acommunity set-up manager 1012, which configures the various end users inaccordance with community creation/modification/deconstructioninstructions received from server 1010. Community set-up manager 1012also interfaces with a bandwidth allocator 1014 in order to enable thebandwidth allocator 1014 to make appropriate bandwidth allocationdeterminations.

[0156] Community set-up manager 1012 also interfaces with aunicast/multicast decision switch 1016, which is operative to sendcontent by unicast, until the simultaneous demand for such contentjustifies sending the content by multicast. Unicast/multicast decisionswitch 1016 is preferably incorporated into a community web server 1018.

[0157] In accordance with a preferred embodiment of the presentinvention, each community is served by a single community web server1018 and associated unicast/multicast decision switch 1016.

[0158] When and so long as simultaneous demand for a given web pageexceeds a given threshold, unicast/multicast switch 1016 triggersbandwidth allocator 1014 to allocate multicast forward path bandwidthfor multicast of that web page. Bandwidth allocator 1014 may employ adynamic pre-emptive queue of URLs for such allocation.

[0159] In practice, the bandwidth allocator 1014 may be responsive tothe amount of available bandwidth for dynamically changing the thresholdof switch 1016.

[0160] In contrast to the embodiment of FIGS. 8A-9B, here all unicasttraffic is forwarded over the broadcast forward path from web server1018 to cache 1008. Bandwidth allocator 1014 takes into account bothunicast and multicast traffic in allocating the available bandwidth ofthe forward path. Bandwidth allocator 1014 essentially makes twodifferent types of decisions: allocation between unicast and multicastand allocation of the multicast bandwidth among communities and URLs. Itis appreciated that the bandwidth allocation is performed by a logicalentity, which may be embodied in one or more physically distributednetwork elements, such as routers.

[0161] Bandwidth allocator 1014 additionally interfaces with a multicastset-up manager 1020 which in turn interfaces with a multicastannouncement server 1022 and a multicast delivery server 1024. Themulticast announcement server 1022 is operative to announce to all endusers in a given community the estimated time and address of upcomingmulticasts. The multicast delivery server 1024 is operative to deliverthe multicasts to the cache 1008, of each end user client 1002associated with the given community.

[0162] Referring now to FIG. 10B, it is appreciated that whereas in theembodiment of FIG. 10A, each community is served by a centralizedcommunity web server 1018, in the embodiment of FIG. 10B, a generic webserver facility 1050, including one or more servers which may be atdisparate locations, is employed to serve multiple communities. In thisembodiment the generic web server facility 1050 communicates with endusers without regard to the communities to which they belong. Therefore,in the embodiment of FIG. 10B, a bandwidth allocator 1054 is preferablyco-located with a unicast/multicast decision switch 1056.

[0163] In the embodiment of FIG. 10B, a community set-up manager 1052interfaces with the unicast/multicast decision switch 1056, hereincorporated with bandwidth allocator 1054, and need not interface withthe generic web server 1050. Preferably, in the embodiment of FIG. 10B,decisions as to which content to multicast or unicast and as to theamount of bandwidth to allocate to the various multicasts are made bythe co-located unicast/multicast decision switch 1056 and bandwidthallocator 1054. Therefore, the generic web server facility 1050 isrequired to continually update the unicast/multicast decision switch1056 as to all web pages queried and as to the community identificationthereof.

[0164] The remainder of the embodiment of FIG. 10B is identical to thatof FIG. 10A. Identical elements are identified in FIG. 10B by the samereference numerals employed in FIG. 10A.

[0165] The embodiment of FIG. 10B has an advantage over the embodimentof FIG. 10A in that in FIG. 10B, the web servers are generic anddistributed among the various communities. A disadvantage of theembodiment of FIG. 10B relative to the embodiment of FIG. 10A is thatgreatly enhanced traffic is generated between generic web serverfacility 1050 and the unicast/multicast decision switch 1056.

[0166] Reference is now specifically made to FIGS. 11A and 11B, whichare simplified flow diagrams corresponding respectively to thesimplified functional block diagrams of FIGS. 10A and 10B.

[0167] Turning to FIG. 11A, it seen that along a time scale from the topof FIG. 11A to the bottom thereof, initially users conduct browsingusing browser 1004 prior to formation of any community. Eventually, dueto action of the profiler 1006, a community is formed by communityset-up manager 1012 in response to a trigger from community creationserver 1010.

[0168] Following formation of a community, when end users who aremembers of the community engage in browsing, using browser 1004, andwhen the demand among members of the community for a given web pageexceeds a threshold established by unicast/multicast decision switch1016 of the community web server 1018, the content of the given web pageis multicast to the entire community subject to bandwidth availabilityconstraints.

[0169] Following the multicast, end users of the community can accessthe content of the given web page from their local cache with nearlyzero latency.

[0170] It is noted that in contrast to the embodiment of FIG. 9A, in theembodiment of FIG. 11A during both pre-community formation browsing andpost-community formation browsing, the community web server 1018requests forward path bandwidth from bandwidth allocator 1014.

[0171] Referring now to FIG. 11B, it is seen that the states of thefunctionality may be identical to those shown in FIG. 11A. A principaldifference is in that whereas in the embodiment of FIG. 11A, thethreshold is established by unicast/multicast decision switch 1016 ofthe community web server 1018, in the embodiment of FIG. 11B, thethreshold is established by the unicast/multicast decision switch 1056,co-located with the bandwidth allocator 1054.

[0172] Reference is now made to FIGS. 12A and 12B, which are simplifiedfunctional block diagrams illustrating two alternative realizations ofthe functionality described in FIGS. 4C, 6B-6E and 7C and also to FIGS.13A and 13B, which are simplified flow diagrams correspondingrespectively to the simplified functional block diagrams of FIGS. 12Aand 12B.

[0173] Referring initially to FIG. 12A, typically two end-user clients1200 and 1202 are shown, it being understood that a multiplicity of suchend-user clients employ the system. Each of the end user clients 1200and 1202 preferably includes a browser 1204 which communicates with aplug-in profiler 1206 and with a standard web cache 1208.

[0174] The standard web cache 1208 may be a standard cache such as anMICROSOFT INTERNET EXPLORER cache or alternatively may be an externalproxy cache such as an APACHE proxy cache.

[0175] The combination of browser 1204 and cache 1208 is employed forconventional web surfing wherein the browser 1204 initially checks cache1208 for requested URLs and only queries a web server, such as thecommunity web server 1218, when the requested URL is not in cache or outof date.

[0176] Plug-in profiler 1206 stores historical surfing informationrelating to pages requested by the browser 1204. Profiler 1206communicates with a community creation server 1210 at predeterminedtimes or at times responsive to various possible criteria.

[0177] The community creation server 1210 preferably communicates withall end-user client profilers 1206. Community creation server 1210preferably analyzes the client profiles and, on the basis of thisanalysis, dynamically creates, modifies and deconstructs communities.

[0178] The community creation server 1210 preferably outputs to acommunity set-up manager 1212, which configures the various end users inaccordance with community creation/modification/deconstructioninstructions received from server 1210. Community set-up manager 1212also interfaces with a bandwidth allocator 1214 in order to enable thebandwidth allocator 1214 to make appropriate bandwidth allocationdeterminations.

[0179] In contrast with the embodiment of FIG. 10A, in the embodiment ofFIG. 12A, the bandwidth allocator 1214 also interfaces with a contentprovider which makes a priori broadcast requests which requireallocation of forward path bandwidth thereto by the bandwidth allocator1214. The content provider may distinguish in its a priori broadcastrequests between “must have” and “nice to have” broadcast requests,allowing the bandwidth allocator 1214 a certain, limited, measure ofdiscretion in terms of allocation of bandwidth for “nice to have”broadcast requests.

[0180] Community set-up manager 1212 also interfaces with aunicast/multicast decision switch 1216, which is operative to sendcontent by unicast, until the simultaneous demand for such contentjustifies sending the content by multicast. Unicast/multicast decisionswitch 1216 is preferably incorporated into a community web server 1218.

[0181] In accordance with a preferred embodiment of the presentinvention, each community is served by a single community web server1218 and associated unicast/multicast decision switch 1216.

[0182] When and so long as simultaneous demand for a given web pageexceeds a given threshold, unicast/multicast switch 1216 triggersbandwidth allocator 1214 to allocate multicast forward path bandwidthfor multicast of that web page. Bandwidth allocator 1214 may employ adynamic pre-emptive queue of URLs for such allocation.

[0183] In practice, the bandwidth allocator 1214 may be responsive tothe amount of available bandwidth for dynamically changing the thresholdof switch 1216.

[0184] All unicast traffic is forwarded over the broadcast forward pathfrom web server 1218 to cache 1208. Bandwidth allocator 1214 takes intoaccount both unicast and multicast traffic in allocating the availablebandwidth of the forward path. Bandwidth allocator 1214 essentiallymakes two different types of decisions: allocation between unicast andmulticast and allocation of the multicast bandwidth among communitiesand URLs. It is appreciated that the bandwidth allocation is performedby a logical entity, which may be embodied in one or more physicallydistributed network elements, such as routers.

[0185] Bandwidth allocator 1214 additionally interfaces with a multicastset-up manager 1220 which in turn interfaces with a multicastannouncement server 1222 and a multicast delivery server 1224. Themulticast announcement server 1222 is operative to announce to all endusers in a given community the estimated time and address of upcomingmulticasts. The multicast delivery server 1218 is operative to deliverthe multicasts to the cache 1208, of each end user client 1202associated with the given community.

[0186] Referring now to FIG. 12B, it is appreciated that whereas in theembodiment of FIG. 12A, each community is served by a centralizedcommunity web server 1218, in the embodiment of FIG. 12B, a generic webserver facility 1250, including one or more servers which may be atdisparate locations, is employed to serve multiple communities. In thisembodiment the generic web server facility 1250 communicates with endusers without regard to the communities to which they belong. Therefore,in the embodiment of FIG. 12B, a bandwidth allocator 1254 is preferablyco-located with a unicast/multicast decision switch 1256.

[0187] In the embodiment of FIG. 12B, a community set-up manager 1252interfaces with the unicast/multicast decision switch 1256, hereincorporated with bandwidth allocator 1254, and need not interface withthe generic web server 1250. Preferably, in the embodiment of FIG. 12B,decisions as to which content to multicast or unicast and as to theamount of bandwidth to allocate to the various multicasts are made bythe co-located unicast/multicast decision switch 1256 and bandwidthallocator 1254. Therefore, the generic web server facility 1250 isrequired to continually update the unicast/multicast decision switch1256 as to all web pages queried and as to the community identificationthereof.

[0188] The remainder of the embodiment of FIG. 12B is identical to thatof FIG. 12A. Identical elements are identified in FIG. 12B by the samereference numerals employed in FIG. 12A.

[0189] The embodiment of FIG. 12B has an advantage over the embodimentof FIG. 12A in that in FIG. 12B, the web servers are generic anddistributed among the various communities. A disadvantage of theembodiment of FIG. 12B relative to the embodiment of FIG. 12A is thatgreatly enhanced traffic is generated between generic web serverfacility 1250 and the unicast/multicast decision switch 1256.

[0190] Reference is now specifically made to FIGS. 13A and 13B, whichare 5 simplified flow diagrams corresponding respectively to thesimplified functional block diagrams of FIGS. 12A and 12B.

[0191] Turning to FIG. 13A, it seen that along a time scale from the topof FIG. 13A to the bottom thereof, initially users conduct browsingusing browser 1204 prior to formation of any community. Eventually, dueto action of the profiler 1206, a community is formed by communityset-up manager 1212 in response to a trigger from community creationserver 1210.

[0192] Following formation of a community, when end users who aremembers of the community engage in browsing, using browser 1204, andwhen the demand among members of the community for a given web pageexceeds a threshold established by unicast/multicast decision switch1216 of the community web server 1218, the content of the given web pageis multicast to the entire community subject to bandwidth availabilityconstraints.

[0193] Following the multicast, end users of the community can accessthe content of the given web page from their local cache with nearlyzero latency.

[0194] During both pre-community formation browsing and post-communityformation browsing, the community web server 1218 requests forward pathbandwidth from bandwidth allocator 1214.

[0195] Referring now to FIG. 13B, it is seen that the states of thefunctionality may be identical to those shown in FIG. 13A. A principaldifference is in that whereas in 25 the embodiment of FIG. 13A, thethreshold is established by unicast/multicast decision switch 1216 ofthe community web server 1218, in the embodiment of FIG. 13B, thethreshold is established by the unicast/multicast decision switch 1256,co-located with the bandwidth allocator 1254.

[0196] Reference is now made to FIG. 14, which is a simplified flowchartillustrating the operation of an algorithm for bandwidth allocation in aunicast-multicast environment, wherein unicast and multicast do notshare the same bandwidth. As seen in FIG. 14, there is provided analgorithm for bandwidth allocation in which a sampling time duration,typically of the order of minutes, is selected, and the currentcommunity size is determined for each community.

[0197] A multicast candidacy threshold for each community is determinedusing data regarding current community size for a selected sampling timeduration. The determination of the multicast candidacy threshold ispreferably carried out as follows:

[0198] An initial assumption is made as to the minimum number of hits ona site for a given population of potential surfers over a given timeduration, which characterizes a “popular site”. The multicast candidacythreshold for each community is taken to be this minimum numbermultiplied by the sampling time duration and multiplied by the currentsize of each community.

[0199] The number of hits per URL for each community during eachsampling time duration is monitored and converted to a URL hit score,which may be weighted according to trends in the number of hits per URL.

[0200] Multicast candidacy of a given site is determined by applying themulticast candidacy threshold to the URL hit score. If a given site isnot considered as a multicast candidate, the number of hits thereon percommunity nevertheless continues to be monitored.

[0201] If a given site is considered to be a multicast candidate, theURL hit score is normalized for the community size and used to create aclout score based not only on per capita popularity but also on thecommunity size. This clout score could be identical to the URL hitscore, but need not necessarily be so, inasmuch as various types oflinear and non-linear weightings may be incorporated in the clout score.

[0202] The candidate sites are queued based on their respective cloutscores. The queue positions of the candidate sites may vary over time inaccordance with variations in their clout scores.

[0203] The content of the site having the highest queue position ismulticasted to the extent of the availability of multicast bandwidth.

[0204] Determination of the multicast candidacy threshold may be made inaccordance with the length of the queue of candidate sites. This may bedone in the following manner:

[0205] If the queue size exceeds a predetermined maximum queuethreshold, the multicast candidacy threshold is modified by increasingthe maximum number of hits on a site for a given population of potentialsurfers over a given time duration, which is required to characterize asite as a “popular site”.

[0206] Similarly, if the queue size falls below a predetermined minimumqueue threshold, the multicast candidacy threshold may be modified byreducing the minimum number of hits on a site for a given population ofpotential surfers over a given time duration, which is required tocharacterize a site as a “popular site”.

[0207] The amount of bandwidth allocated to multicasting of site contentto members of each community may be monitored.

[0208] Reference is now made to FIG. 15, which is a simplified flowchartillustrating the operation of an algorithm for bandwidth allocation in aunicast-multicast environment, wherein unicast and multicast share thesame bandwidth. As seen in FIG. 14, a sampling time duration, typicallyof the order of minutes, is selected and the current community size isdetermined for each community.

[0209] A multicast candidacy threshold for each community is determinedusing data regarding current community size for a selected sampling timeduration. The determination of the multicast candidacy threshold ispreferably carried out as follows:

[0210] An initial assumption is made as to the minimum number of hits ona site for a given population of potential surfers over a given timeduration, which characterizes a “popular site”. The multicast candidacythreshold for each community is taken to be this minimum numbermultiplied by the sampling time duration and multiplied by the currentsize of each community.

[0211] The number of hits per URL for each community during eachsampling time duration is monitored and converted to a URL hit score,which may be weighted according to trends in the number of hits per URL.

[0212] Multicast candidacy of a given site is determined by applying themulticast candidacy threshold to the URL hit score. If a given site isnot considered as a multicast candidate, the number of hits thereon percommunity nevertheless continues to be monitored.

[0213] If a given site is considered to be a multicast candidate, theURL hit score is normalized for the community size and used to create aclout score based not only on per capita popularity but also on thecommunity size. This clout score could be identical to the URL hitscore, but need not necessarily be so, in as much as various types oflinear and non-linear weightings may be incorporated in the clout score.

[0214] The candidate sites are queued based on their respective cloutscores. The queue positions of the candidate sites may vary over time inaccordance with variations in their clout scores.

[0215] The content of the site having the highest queue position ismulticasted to the extent of the availability of multicast bandwidth. Inthe embodiment of FIG. 15, the availability of multicast bandwidth isdetermined in part by the utilization of commonly available bandwidth byunicast, which has a higher priority than multicast. Thus it may beunderstood that multicast bandwidth is “leftover” bandwidth which is notutilized by unicast.

[0216] The embodiment of FIG. 15, which involves sharing bandwidthbetween unicast and multicast, has an additional important features thatincreased multicasting of site content lowers the requirement forunicast bandwidth. This, in turn, makes more multicast bandwidthavailable. The increased availability of multicast bandwidth tends toreduce the length of the queue for transmission With this in mind, itmay be appreciated that determination of the multicast candidacythreshold may be made in accordance with the length of the queue ofcandidate sites, typically in a manner somewhat different from thatdescribed hereinabove in connection with FIG. 14.

[0217] If the queue size falls below a predetermined queue threshold,similarly to the situation in FIG. 14, the multicast candidacy thresholdis modified by reducing the minimum number of hits on a site for a givenpopulation of potential surfers over a given time duration, which isrequired to characterize a size as a “popular site”. In this case,however, the multicast candidacy threshold is not permitted to fallbelow a minimum multicast candidacy threshold. If the minimum multicastcandidacy threshold is reached, the remaining available bandwidth isallocated to unicast transmission in order to reduce latency thereof.

[0218] Reference is now made to FIG. 16, which is a simplified flowchartillustrating the operation of an algorithm for bandwidth allocation in aunicast-multicast environment, wherein unicast, a priori multicast andtriggered multicast share the same bandwidth. As seen in FIGS. 14 and15, a sampling time duration, typically of the order of minutes, isselected and the current community size is determined for eachcommunity.

[0219] A multicast candidacy threshold for each community is determinedusing data regarding current community size for a selected sampling timeduration. The determination of the multicast candidacy threshold ispreferably carried out as follows:

[0220] An initial assumption is made as to the minimum number of hits ona site for a given population of potential surfers over a given timeduration, which characterizes a “popular site”. The multicast candidacythreshold for each community is taken to be this minimum numbermultiplied by the sampling time duration and multiplied by the currentsize of each community.

[0221] The number of hits per URL for each community during eachsampling time duration is monitored and converted to a URL hit score,which may be weighted according to trends in the number of hits per URL.

[0222] Multicast candidacy of a given site is determined by applying themulticast candidacy threshold to the URL hit score. If a given site isnot considered as a multicast candidate, the number of hits thereon percommunity nevertheless continues to be monitored.

[0223] If a given site is considered to be a multicast candidate, theURL hit score is normalized for the community size and used to create aclout score based not only on per capita popularity but also on thecommunity size. This clout score could be identical to the URL hitscore, but need not necessarily be so, inasmuch as various types oflinear and non-linear weightings may be incorporated in the clout score.

[0224] The candidate sites are queued based on their respective cloutscores. The queue positions of the candidate sites may very over time inaccordance with variations in their clout scores.

[0225] The content of the site having the highest queue position ismulticasted to the extent of the availability of multicast bandwidth. Inthe embodiment of FIG. 16, the availability of multicast bandwidth isdetermined in part by the utilization of commonly available bandwidth byunicast, which has a higher priority than multicast and in part by apriori multicast broadcasting.

[0226] A priori multicast broadcasting typically includes a portion,here termed 30 “must have”, which has the highest priority forbandwidth, exceeding that of unicast and all other multicast. A priorimulticast broadcasting may also include a portion, here termed “nice tohave”, which has a lower priority than “must have” and typically has thesame priority as other multicast transmissions. In the preferredembodiment of FIG. 16, “nice to have” multicast, is given a static cloutscore which is an average clout score among multicast candidates.

[0227] Thus it may be understood that unicast bandwidth is “leftover”bandwidth which is not utilized by “must have” a priori multicast andnon “must have” multicast bandwidth, including “nice to have” a prioriand other multicast, is “leftover” bandwidth which is not utilized byunicast.

[0228] The embodiment of FIG. 16, which involves sharing bandwidthbetween a priori multicast, unicast and multicast, also has theadditional feature that increased multicasting of site content lowersthe requirement for unicast bandwidth. This, in turn, makes moremulticast bandwidth available. The increased availability of multicastbandwidth tends to reduce the length of the queue for transmission. Withthis in mind, it may be appreciated that determination of the multicastcandidacy threshold may be made in accordance with the length of thequeue of candidate sites, typically in a manner described hereinabove inconnection with FIG. 15.

[0229] It will be appreciated by persons skilled in the art that thepresent invention is not limited by what has been particularly shown anddescribed hereinabove. Rather the scope of the present inventionincludes both combinations and subcombinations of the various featuresdescribed hereinabove as well as variations and modifications whichwould occur to persons skilled in the art upon reading the specificationand which are not in the prior art.

1. A system for providing content to users comprising: a multicastsub-system providing content to multiple users; and a unicast sub-systemproviding content to individual users, said multicast sub-system beingoperative to push to each of a plurality of user communities, contentrelating to said community, and said unicast sub-system being operativeto provide on demand to a user, content which has not been previouslypushed to said user.
 2. A system for providing content to usercomprising: a multicast sub-system providing content to multiple usersand being operative to push to each of a plurality of user communities,content relating to said community; and a bandwidth allocator operativeto allocate bandwidth used by said multicast sub-system among saidplurality of user communities.
 3. A system for providing content tousers comprising: at least one multicast sub-system providing content tomultiple users; at least one unicast sub-system providing content toindividual users; and a bandwidth allocator operative to allocatebandwidth among said at least one multicast sub-system and said at leastone unicast sub-system.
 4. A system for providing content to userscomprising: a multicast sub-system providing content to multiple usersand being operative to push to each of a plurality of user communities,content relating to said community based on at least a-priorideterminations and current demand; and a bandwidth allocator operativeto allocate bandwidth used by said multicast sub-system among at leastcontent based on a-priori determinations and content based on currentdemand.
 5. A system for providing content to users comprising: multicast means for providing content to multiple users;.and unicast meansfor providing content to individual users, said multicast means beingoperative to push each of a plurality of user communities, contentrelating to said community, and said unicast means being operative toprovide on demand to a user, content which has not been previouslypushed to said user.
 6. A system for providing content to usercomprising: multicast means providing content to multiple users andbeing operative to push to each of a plurality of user communities,content relating to said community; and bandwidth allocator meansoperative to allocate bandwidth used by said multicast means among saidplurality of user communities.
 7. A system for providing content tousers comprising: at least one multicast means for providing content tomultiple users; at least one unicast means for providing content toindividual users; and bandwidth allocator means operative to allocatebandwidth among said at least one multicast means and said at least oneunicast means.
 8. A system for providing content to users comprising:multicast means for providing content to multiple users and beingoperative to push to each of a plurality of user communities, contentrelating to said community based on at least a priori determinations andcurrent demand; and a bandwidth allocator operative to allocatebandwidth used by said multicast means among at least content based on apriori determinations and content based on current demand.
 9. A systemfor providing unicast and multicast content to users and includingbandwidth allocation means for providing a guaranteed minimum level ofunicast service to the extent required and wherein bandwidth remainingfrom the provision of the guaranteed minimum level of unicast service isemployed for multicast, the same broadcast network providing bothunicast and multicast.
 10. A system for providing unicast and multicastcontent to users and including bandwidth allocation means for allocatinghighest priority to a-priori content and next highest priority tounicast and for allocating remaining bandwidth to multicast.
 11. Asystem according to any of claims 1-10 and also comprising a pluralityof satellites having at least one of the following functionalities:broadcast, multicast and unicast.
 12. A system according to any ofclaims 1-10 and comprising at least one of cable, networks, digitalterrestrial networks, microwave networks, cellular networks and DSLnetworks, having at least one of the following functionalities:broadcast, multicast and unicast
 13. A system according to any of claims1-12 and comprising PSTN facilities providing unicast functionality. 14.A system according to any of claims 1-13 and wherein unicastfunctionality is provided by facilities which also simultaneouslyprovide broadcast and multicast functionalities.
 15. A system accordingto any of claims 1-14 and wherein broadcast includes transmission ofcontent to all users within a geographical footprint of a broadcast,including transmission of content in a pay access regime.
 16. A systemaccording to any of claims 1-15 and wherein multicast includestransmission of content to all users within a community having apredefined common interest, within a geographical footprint of abroadcast.
 17. A system according to any of claims 1-16 and whereinunicast includes transmission of content to an individual user based ona request from that user.
 18. A system according to any of claims 1-17and wherein at least one coordinating facility coordinates unicastfunctionality with at least one of broadcast and multicastfunctionalities, thereby to enable efficient and effective use ofavailable resources in terms of transmission facilities and bandwidth.19. A system according to claim 18 and wherein said at least onecoordinating functionality provides at least one of the followingfunctionalities: shifting between unicasting and multicasting; bandwidthallocation within multicast communities; and bandwidth allocationbetween unicast, multicast and a priori broadcast or multicast content.20. A system according to claim 18 and wherein said at least onecoordinating functionality is operative to determine what content issent in what manner at what time via which facilities to which users.21. A system according to any of claims 18-20 and wherein said at leastone coordinating functionality is operative to create new multicastcommunities in response to an increase in common user interests andrequests.
 22. A system according to any of claims 18-21 and wherein saidat least one coordinating functionality is operative to eliminatemulticast communities in response to a decrease in common user interestsand requests.
 23. A system according to any of claims 1-21 and whereinas a community grows, the amount of bandwidth allocated to thatcommunity increases.
 24. A system according to any of claims 1-23 andwherein as a community decreases in size, the amount of bandwidthallocated to the community decreases.
 25. A system according to any ofclaims 1-23 and wherein there is defined a minimum multicast thresholdwhich is a relative threshold determined by relative demands for variousavailable content.
 26. A system according to any of claims 1-25 andwherein the system provides a guaranteed minimum level of unicastservice to the extent required and wherein bandwidth remaining from theprovision of the guaranteed minimum level of unicast service is employedfor multicast, the same broadcast network providing both unicast andmulticast.
 27. A system according to any of claims 1-26 and whereinbandwidth not required for contractual unicast service is allocated tomulticast, thereby reducing demand for contractual unicast service andthus, over time, decreasing latency and providing enhanced service tocustomers.
 28. A system according to any of claims 1-27 and whereinbandwidth not required for contractual unicast service is allocated notonly to multicast but also to better unicast service, in accordance withlatency considerations.
 29. A system according to any of claims 1-9 and11-28 and wherein available bandwidth is allocated with the highestpriority being given to a-priori content and the next highest prioritybeing given to unicast the remaining bandwidth being employed formulticast.
 30. A system according to claim 29 and wherein said remainingbandwidth is allocated among communities based at least partially onrelative community size.
 31. A method for providing content to userscomprising: multicasting content to multiple users; and unicastingcontent to individual users. said multicasting including pushing to eachof a plurality of user communities, content relating to said community,and said unicasting including provide on demand to user, content whichhas not been previously pushed to said user.
 32. A method for providingcontent to user comprising: multicasting content to multiple users bypushing content relating to individual communities; and allocatingbandwidth among said individual communities.
 33. A method for providingcontent to users comprising: multicasting content to multiple users;unicasting content to individual users; and allocating bandwidth betweensaid multicasting and said unicasting.
 34. A method for providingcontent to users comprising: multicasting content to multiple users bypushing to each of a plurality or user communities, content relating tosaid community based on at least a priori determinations and currentdemand; and allocating bandwidth among at least content based on apriori determinations and content based on current demand.
 35. A methodfor providing unicast and multicast content to users and includingbandwidth allocation wherein bandwidth remaining from the provision ofthe guaranteed minimum level of unicast service is employed formulticast, the same broadcast network providing both unicast andmulticast.
 36. A method for providing unicast and multicast content tousers and including bandwidth allocation, allocating highest priority toa-priori content and next higher priority to unicast and for allocatingremaining bandwidth to multicast.
 37. A method according to any ofclaims 31-36 and including broadcast of content to all users within ageographical footprint of a broadcast, including transmission of contentin a pay access regime.
 38. A method according to any of claims 31-37and wherein multicasting includes transmission of content to all userswithin a community having a predefined common interest, within ageographical footprint of a broadcast.
 39. A method according to any ofclaims 31-38 and wherein unicasting includes transmission of content toan individual user based on a request from that user.
 40. A methodaccording to any of claims 31-39 and wherein at least one coordinatingfacility coordinates unicast functionality with at least one ofbroadcast and multicast functionalities, thereby to enable efficient andeffective use of available resources in terms of transmission facilitiesand bandwidth.
 41. A method according to claim 40 and wherein said atleast one coordinating functionality provides at least one of thefollowing functionalities: shifting between unicasting and multicasting;bandwidth allocation within multicast communities; and bandwidthallocation between unicast, multicast and a priori broadcast ormulticast content.
 42. A method according to claim 40 and wherein saidat least one coordinating functionality is operative to what content issent in what manner at what time facilities to which users.
 43. A methodaccording to any of claims 40-42 and wherein said at least onecoordinating functionality is operative to create new multicastcommunities in response to an increase in common user interests andrequests.
 44. A method according to any of claims 40-43 and wherein saidat least one coordinating functionality is operative to eliminatemulticast communities in response to a decrease in common user interestsand requests.
 45. A method according to any of claims 31-44 and whereinas a community grows, the amount of bandwidth allocated to thatcommunity increases.
 46. A method according to any of claims 31-45 andwherein as a community decreases in size, the amount of bandwidthallocated to that community decreases.
 47. A method according to any ofclaims 31-46 and including providing a guaranteed minimum level ofunicast service to the extent required and wherein bandwidth remainingfrom the provision of the guaranteed minimum level of unicast service isemployed for multicast, the same broadcast network providing bothunicast and multicast.
 48. A method according to any of claims 31-47 andwherein bandwidth not required for contractual unicast service isallocated to multicast, thereby reducing demand for contractual unicastservice and thus, over time, decreasing latency and providing enhancedservice to customers.
 49. A method according to any of claims 31-48 andwherein bandwidth not required for contractual unicast service isallocated not only to multicast but also to better unicast service, inaccordance with latency considerations.
 50. A method according to any ofclaims 31-34 and 37-49 and wherein available bandwidth is allocated withthe highest priority being given to a-priori content and the nexthighest priority being given to unicast, the remaining bandwidthemployed being for multicast.
 51. A method according to claim 50 andwherein said remaining bandwidth is allocated among communities based atleast partially on relative community size.